This disclosure relates to use of a router in a charging system to account for service provided by a network element (NE) of a service provider network. Exemplary embodiments of the router and methods for its use are described. The router acts as a proxy for receiving accounting requests (ACRs) from NEs in the service provider network and routing the ACRs to charging control functions (CCFs) in the charging system and vice versa for accounting answers (ACAs). The router provides intelligence for further processing of ACRs when the ACA indicates certain types of error or failure conditions, such as overload and transient failure conditions. For these conditions, the router can determine whether or not to re-try sending the ACR to the same CCF or to select an alternate CCF. If the subsequent attempt by the router to submit the ACR for processing is successful, the problem is resolved without involving the NE. Various embodiments are described for error and failure conditions in which the ACA indicates the CCF is too busy to process the ACR (i.e., Result Code 3004) or that the CCF is at least temporarily out of space to process the ACR (i.e., Result Code 4002). However, the methods and apparatus described herein may also be used to process other types of error and failure conditions.
In telecommunication and data networks, offline charging is provided by a multitude of servers implementing a CCF. The CCF is an integral part of business operations for a service provider. The CCF may include a plurality of CCF servers (i.e., nodes) to accumulate charges for communications sessions associated with a service provider network. For example, the service provider network may include various legacy communication networks, internet protocol (IP) multimedia subsystem (IMS) networks, long term evolution (LTE) networks, and other suitable communication service networks in any suitable combination. The CCF receives ACRs from signaling and bearer NEs in these communication service networks. The NEs implement a charging trigger function (CTF). CTFs integrated within the NEs provide ACRs to the CCF. The accounting can be discrete as in an event, such as sending or receiving a short message or related to a session which begins with a start notification, zero or more interim accounting message, and finishes with a stop notification. The CCF acknowledges ACR messages via ACA messages. ACR and ACA messages, for example, may be based on the Diameter Base Protocol (see Request for Comments (RFC) 3588), The contents of RFC 3588 Diameter Base Protocol are fully incorporated herein by reference. The Diameter Base Protocol runs on transmission control protocol (TCP)/IP or stream control transmission protocol (SCTP).
In large networks, it is common to see hundreds of CTFs and tens of CCF servers in the CCF. For reasons of security, it is typical to have the identity of the CTFs provisioned at the CCF servers. This ensures that when accounting messages arrive from a CTF, the corresponding CCF server can determine that the messages are coming from a known or trusted host. However, this security aspect gives rise to a provisioning problem, where each of the hundreds of CTFs must be individually defined in each of the tens of CCF servers. To alleviate this problem, a Diameter Router (D-RTR) may be employed. For example, FIG. 1 shows a charging system with a D-RTR. The D-RTR acts as an intelligent proxy or intelligent router. For example, each session reported from each of the hundreds of CTFs may terminate at the D-RTR. Correspondingly, D-RTR initiates messaging toward the CCF servers. Responses from the CCF servers terminate at the D-RTR. The D-RTR conveys the responses back to the original CTF that initiated the corresponding ACR.                Network Elements<D-RTR>CCF-1, CCF-2 . . . CCF-N        Implement CTF<Function>        
Here, the task of the D-RTR is to ensure that ACRs are more or less evenly distributed among the CCF servers. Unlike a client-based CCF load distribution function (LDF) within the CTFs, which can be viewed as a simple round-robin methodology for each communication session in which the CTF is participating, the D-RTR must operate within two principle constraints while serving a plurality of CTFs and a plurality of CCF servers: 1) the ACRs within a Diameter session from one NE/CTF must be forwarded to the same CCF server and 2) the ACA message sent in response by the CCF server must be conveyed to the NE/CTF originator of the corresponding ACR.
The advantage of the D-RTR is that it hides the network topology on one hand so that the CTFs can use the D-RTR as the destination of their ACR messages, without having to worry about selection of a CCF server or an alternate peer, for instance, in case of CCF outage or failure conditions. The D-RTR provides the additional benefit that it can monitor the count of ongoing sessions, or even the individual CCF server's load carrying capacity, in order to determine the destination for a new accounting session. This keeps the CCF servers more or less loaded at or under their engineered limits.
However, it is the topology hiding part that creates an additional problem. In existing configurations, when a specific CCF server develops overload or reports a transient error condition and indicates to the NE/CTF to try an alternate peer, as per RFC 3588, the corresponding NE/CTF would not know how to react to this because it would not be able to choose an alternate peer because the topology of the CCF servers are hidden from the view of the corresponding NE/CTF. In existing D-RTR configurations, in case the NE/CTF retransmits the ACR, the D-RTR, working under the first principle constraint mentioned above (i.e., forwarding ACRs from a given CTF to the same CCF server for a given session) would tend to send the ACR to the same CCF server that just indicated that the CTF should choose an alternate peer. This creates an infinite or endless loop situation, at least until the overloaded CCF server can recover from the overload condition or until the transient error subsides. The situation is further exacerbated and the recovery of the overloaded CCF server is further delayed since the D-RTR keeps resending the ACR messages to the same CCF server because it is generally not aware of the load situation at the CCF server.
Based on the foregoing, techniques that enable a router in a charging system to provide intelligent message processing of ACRs when a CCF server currently selected for processing the ACR is experiencing certain types of error or failure conditions. Additionally, it is desirable that the router be able to resolve such conditions without involving the NE that originated the ACR.